IEEE 802.1x is known as one authentication standard for performing authentication via a network. In IEEE 802.1x, as shown in FIG. 20, a configuration is known where a switch 901 provided with an authenticator function cooperates with an Authentication Server 900 and performs access control. Furthermore, as shown in FIG. 21, a configuration is known where, in an initial state (an unauthenticated state), an EAPoL (Extensible Authentication Protocol over LAN) pass switch 904 that only passes EAPoL frames is arranged, and access to the Authenticator 901 is allowed.
It is to be noted that, as shown in FIG. 22, with an EAPoL frame, identification is possible according to a value of a TYPE field of a MAC frame being “888E”, and identification of message type is possible according to a value of a Ptype field. For example, if the value of the Ptype field is “0”, identification that this is an EAP packet is performed, and if the value of the Ptype field is “1”, identification is made of an EAPoL Start message.
In recent years, technology known as OpenFlow has been proposed (Non-Patent Document 1). In OpenFlow, communication is taken as end-to-end flow, and path control, recovery from failure, load balancing, and optimization are performed in flow units. An OpenFlow switch functioning as a forwarding node is provided with a secure channel for communication with an OpenFlow controller, and operates according to a flow table in which appropriate addition or rewriting is instructed by an OpenFlow controller. In the flow table are definitions of sets of rules (FlowKey) for collation with packet headers, actions (Actions) defining processing content, and flow statistical information (Stats), for each flow (refer to FIG. 4).
FIG. 23 shows an example of action names and action content defined in Non-Patent Document 2. OUTPUT is an action for outputting to a specific port (interface). From SET_VLAN_VID to SET_TP_DST are actions for correcting fields of a packet header.
For example, when an OpenFlow switch receives a packet, an entry is searched for that has a rule (FlowKey) matching header information of the received packet, from the flow table. As a result of the search, in a case where an entry matching the received packet is found, the OpenFlow switch implements processing content described in an action field of the entry in question, for the received packet. On the other hand, as a result of the search, in a case where an entry matching the received packet is not found, the OpenFlow switch forwards the received packet to the OpenFlow controller via a secure channel, requests determination of a path of the packet based on source and destination of the received packet, receives a flow entry for realizing this, and updates the flow table.